SSL- und Nicht-SSL-Protokolle mit NGINX 1.15.2 über denselben Port betreiben

NGINX | 24. Juli 2018

Wir freuen uns, heute die Verfügbarkeit von NGINX Open Source 1.15.2 bekannt geben zu können. Eine wichtige Neuerung in dieser Version ist die neue Variable „$ssl_preread_protocol“, mit der Sie beim Weiterleiten von Datenverkehr über einen TCP-Proxy (stream) zwischen SSL/TLS und anderen Protokollen unterscheiden können. Dies ist hilfreich, wenn Sie Firewall-Beschränkungen umgehen möchten, indem Sie beispielsweise SSL/TLS- und SSH-Dienste über denselben Port betreiben.

Die neue Funktion wird mit der kommenden Version NGINX Plus R16 auch für Kunden von NGINX Plus verfügbar sein.

When and How to Use $ssl_preread_protocol

Wenn Sie SSL/TLS-Datenverkehr mit den Modulen http oder stream terminieren und entschlüsseln, erfasst die Variable $ssl_protocol (http, stream) die vom Client verwendete SSL- oder TLS-Version. Manchmal möchten Sie SSL/TLS-Datenverkehr jedoch lediglich weiterleiten, ohne ihn zu entschlüsseln, und dazu mit den stream-Modulen einen einfachen TCP-Proxy oder Load-Balancer implementieren.

Das Modul stream_ssl_preread untersucht die anfängliche ClientHello-Nachricht in einer SSL- oder TLS-Verbindung und extrahiert mehrere Werte, die zur Verwaltung der Verbindung verwendet werden können. Die mit Version 1.15.2 hinzugefügte Variable $ssl_preread_protocol erfasst die neueste SSL/TLS-Versionsnummer aus dem Feld client_version der ClientHello-Nachricht. Wenn die Erweiterung supported_versions in der ClientHello-Nachricht vorhanden ist, wird die Variable auf TLSv1.3 gesetzt.

Wenn eine Verbindung keine SSL- oder TLS-Version verwendet, bleibt die Variable „$ssl_preread_protocol“ leer. Dies weist darauf hin, dass die Verbindung ein anderes Protokoll als SSL/TLS verwendet, beispielsweise SSH.

Das folgende Konfigurationsbeispiel verwendet die Variable $ssl_preread_protocol in einem map-Block, um die Variable $upstream auf den Namen der Upstream-Gruppe festzulegen, die für das von der Verbindung verwendete Protokoll geeignet ist. Die Direktive proxy_pass leitet die Anfrage anschließend an die ausgewählte Upstream-Gruppe weiter. Beachten Sie, dass die Direktive ssl_preread on im server-Block enthalten sein muss, damit die Variable $ssl_preread_protocol funktioniert.

stream {    upstream ssh {
        server 192.0.2.1:22;
    }

    upstream web {
        server 192.0.2.2:443;
    }

    map $ssl_preread_protocol $upstream {
        default ssh;
        "TLSv1.2" web;
    }

    # SSH and SSL on the same port
    server {
        listen 443;

        proxy_pass $upstream;
        ssl_preread on;
    }
}

Damit die Konfiguration wirksam wird, müssen Clients statt über den Standardport 22 über Port 443 auf den SSH-Server zugreifen. Mit dem integrierten SSH-Client unter macOS und Linux können Sie beispielsweise mit der Option -p den Port ändern:

$ ssh ssh-server-ip-address -p 443

So erhalten Sie die neueste NGINX-Version

Die neueste Version von NGINX ist stets im Mainline-Zweig unseres offiziellen Repositorys verfügbar.

Mehr erfahren

NGINX Open Source 1.15.2 enthält weitere Verbesserungen und Fehlerbehebungen. Eine vollständige Liste der Neuerungen finden Sie im NGINX-Änderungsprotokoll.


Teilen

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.